Shining Light On Shadow Stacks

Control-Flow Hijacking attacks are the dominant attack vector against C/C++ programs. Control-Flow Integrity (CFI) solutions mitigate these attacks on the forward edge,i.e., indirect calls through function pointers and virtual calls. Protecting the backward edge is left to stack canaries, which are easily bypassed through information leaks. Shadow Stacks are a fully precise mechanism for protecting backwards edges, and should be deployed with CFI mitigations. We present a comprehensive analysis of all possible shadow stack mechanisms along three axes: performance, compatibility, and security. For performance comparisons we use SPEC CPU2006, while security and compatibility are qualitatively analyzed. Based on our study, we renew calls for a shadow stack design that leverages a dedicated register, resulting in low performance overhead, and minimal memory overhead, but sacrifices compatibility. We present case studies of our implementation of such a design, Shadesmar, on Phoronix and Apache to demonstrate the feasibility of dedicating a general purpose register to a security monitor on modern architectures, and the deployability of Shadesmar. Our comprehensive analysis, including detailed case studies for our novel design, allows compiler designers and practitioners to select the correct shadow stack design for different usage scenarios.Comment: To Appear in IEEE Security and Privacy 201

Lockdown: Dynamic Control-Flow Integrity

Applications written in low-level languages without type or memory safety are especially prone to memory corruption. Attackers gain code execution capabilities through such applications despite all currently deployed defenses by exploiting memory corruption vulnerabilities. Control-Flow Integrity (CFI) is a promising defense mechanism that restricts open control-flow transfers to a static set of well-known locations. We present Lockdown, an approach to dynamic CFI that protects legacy, binary-only executables and libraries. Lockdown adaptively learns the control-flow graph of a running process using information from a trusted dynamic loader. The sandbox component of Lockdown restricts interactions between different shared objects to imported and exported functions by enforcing fine-grained CFI checks. Our prototype implementation shows that dynamic CFI results in low performance overhead.Comment: ETH Technical Repor

Forgery-Resistant Touch-based Authentication on Mobile Devices

Mobile devices store a diverse set of private user data and have gradually become a hub to control users' other personal Internet-of-Things devices. Access control on mobile devices is therefore highly important. The widely accepted solution is to protect access by asking for a password. However, password authentication is tedious, e.g., a user needs to input a password every time she wants to use the device. Moreover, existing biometrics such as face, fingerprint, and touch behaviors are vulnerable to forgery attacks. We propose a new touch-based biometric authentication system that is passive and secure against forgery attacks. In our touch-based authentication, a user's touch behaviors are a function of some random "secret". The user can subconsciously know the secret while touching the device's screen. However, an attacker cannot know the secret at the time of attack, which makes it challenging to perform forgery attacks even if the attacker has already obtained the user's touch behaviors. We evaluate our touch-based authentication system by collecting data from 25 subjects. Results are promising: the random secrets do not influence user experience and, for targeted forgery attacks, our system achieves 0.18 smaller Equal Error Rates (EERs) than previous touch-based authentication.Comment: Accepted for publication by ASIACCS'1

DP-ACT: Decentralized Privacy-Preserving Asymmetric Digital Contact Tracing

Digital contact tracing substantially improves the identification of high-risk contacts during pandemics. Despite several attempts to encourage people to use digital contact-tracing applications by developing and rolling out decentralized privacy-preserving protocols (broadcasting pseudo-random IDs over Bluetooth Low Energy-BLE), the adoption of digital contact tracing mobile applications has been limited, with privacy being one of the main concerns.In this paper, we propose a decentralized privacy-preserving contact tracing protocol, called DP-ACT, with both active and passive participants. Active participants broadcast BLE beacons with pseudo-random IDs, while passive participants model conservative users who do not broadcast BLE beacons but still listen to the broadcasted BLE beacons. We analyze the proposed protocol and discuss a set of interesting properties. The proposed protocol is evaluated using both a face-to-face individual interaction dataset and five real-world BLE datasets. Our simulation results demonstrate that the proposed DP-ACT protocol outperforms the state-of-the-art protocols in the presence of passive users

An Evil Copy: How the Loader Betrays You

Abstract-Dynamic loading is a core feature used on current systems to (i) enable modularity and reuse, (ii) reduce memory footprint by sharing code pages of libraries and executables among processes, and (iii) simplify update procedures by eliminating the need to recompile executables when a library is updated. The Executable and Linkable Format (ELF) is a generic specification that describes how executable programs are stitched together from object files produced from source code to libraries and executables. Programming languages allow fine-grained control over variables, including access and memory protections, so programmers may write defense mechanisms assuming that the permissions specified at the source and/or compiler level will hold at runtime. Unfortunately, information about memory protection is lost during compilation. We identify one case that has significant security implications: when instantiating a process, constant external variables that are referenced in executables are forcefully relocated to a writable memory segment without warning. The loader trades security for compatibility due to the lack of memory protection information on the relocated external variables. We call this new attack vector COREV for Copy Relocation Violation. An adversary may use a memory corruption vulnerability to modify such "read-only" constant variables like vtables, function pointers, format strings, and file names to bypass defenses (like FORTIFY SOURCE or CFI) and to escalate privileges. We have studied all Ubuntu 16.04 LTS packages and found that out of 54,045 packages, 4,570 packages have unexpected copy relocations that change read-only permissions to read-write, presenting new avenues for attack. The attack surface is broad with 29,817 libraries exporting relocatable read-only variables. The set of 6,399 programs with actual copy relocation violations includes ftp servers, apt-get, and gettext. We discuss the cause, effects, and a set of possible mitigation strategies for the COREV attack vector

Top of the Heap: Efficient Memory Error Protection for Many Heap Objects

Exploits against heap memory errors continue to be a major concern. Although many defenses have been proposed, heap data are not protected from attacks that exploit memory errors systematically. Research defenses focus on complete coverage of heap objects, often giving up on comprehensive memory safety protection and/or incurring high costs in performance overhead and memory usage. In this paper, we propose a solution for heap memory safety enforcement that aims to provide comprehensive protection from memory errors efficiently by protecting those heap objects whose accesses are provably safe from memory errors. Specifically, we present the Uriah system that statically validates spatial and type memory safety for heap objects, isolating compliant objects on a safe heap that enforces temporal type safety to prevent attacks on memory reuse. Using Uriah, 71.9% of heap allocation sites can be shown to produce objects (73% of allocations are found safe) that satisfy spatial and type safety, which are then isolated using Uriah's heap allocator from memory accesses via unsafe heap objects. Uriah only incurs 2.9% overhead and only uses 9.3% more memory on SPEC CPU2006 (C/C++) benchmarks, showing that many heap objects can be protected from all classes of memory errors efficiently